Il y a deux jours, Microsoft a diffusé la mise à jour KB5039302 pour Windows 10 et 11. Contrairement aux mises à jour mensuelles (chaque deuxième mardi de chaque mois) dédiées à la sécurité, elle apportait plusieurs améliorations fonctionnelles pour Windows 11.
Le bouton permettant d’afficher rapidement le bureau est ainsi revenu par défaut. L’Explorateur de fichiers a gagné la capacité de créer des archives 7-Zip et TAR, le menu Partage reçoit une fonction Copier, le support de la norme Emoji passe à la version 15.1 (mouvements de tête, citron vert, phénix…) ainsi qu’un certain nombre de corrections de bugs.
Mais cette KB5039302 introduit un loup. Comme pointé par Neowin et confirmé par Microsoft dans la liste des problèmes connus pour les versions 22H2 et 23H2 de Windows 11, la nouvelle mise à jour peut entrainer des redémarrages en boucle chez certains utilisateurs.
« Ce problème est plus susceptible d'affecter les appareils utilisant des outils de machines virtuelles et des fonctions de virtualisation imbriquées, telles que CloudPC, DevBox, Azure Virtual Desktop. Nous enquêtons pour déterminer les conditions précises dans lesquelles ce problème peut se déclencher », indique Microsoft.
« Les utilisateurs de l'édition familiale de Windows sont moins susceptibles de rencontrer ce problème, car la virtualisation est moins répandue dans les environnements domestiques », ajoute l’entreprise. Elle a donc décidé de suspendre le déploiement de la mise à jour. Une nouvelle version sera proposée quand la cause du problème aura été déterminée.
Heureusement, cette mise à jour n’est pas déployée automatiquement, contrairement aux correctifs de sécurité. Pour l’obtenir, il faut avoir cliqué sur le bouton « Rechercher des mises à jour » dans Windows Update et activé le réglage « Recevez les dernières mises à jour dès qu’elles sont disponibles ».
Commentaires (23)
#1
(Je sais même plus comment aller dans le mode sans echec de Windows 11 tellement le boot a changé ^^' )
Historique des modifications :
Posté le 28/06/2024 à 10h51
Question bête mais si ta machine reboot en boucle. Tu fais quoi ? Mode sans echec et uninstall de l'update en question ?
(Je sais même si ya un mode dans echec dans Windows 11 tellement le boot a changé ^^' )
#1.1
#1.2
Et normalement, il y a un point de restauration créé avant chaque installation de mise à jour.
#1.3
Dans ce cas on sait pas si le reboot se fait une fois dans Windows ou avant le login.
Il faut encore espérer que le mode sans echec ne soit pas affecté par cette update
Historique des modifications :
Posté le 28/06/2024 à 11h32
Y'avait pas un truc dans Windows que quand le boot a fonctionné, c'est considéré comme une bonne config par Windows. Et si on choisis "revenir a une configuration fonctionnelle" en mode sans echec, il va juste revenir a une config problématique![:fou:](https://cdn2.nextinpact.com/smileys/fou.gif)
![:D](https://cdn2.nextinpact.com/smileys/icon_mrgreen.gif)
Il faut encore espérer que le mode sans echec ne soit pas affecté par cette update
#1.4
#1.5
Cela fait 1 an que j'ai une petit CG Nvidia GT1030. Ils se sont améliorés, je n'ai plus eu de BSOD après mise à jour du driver (2 fois), mais un affichage qui saute environ toute les 6 secondes pour une dizaine de secondes, avec les 2 maj de drivers installées depuis 1 an :( Mauvaise pioche?
#1.6
Et d'ordre général, quand ça concerne ma seule machine sous Windows qui n'est qu'une console Steam / FFXIV, je cherche pas à savoir plus. En dehors de ça, j'ai eu toute ma vie des Nvidia et ne m'en suis jamais plaint. Mon seul GPU ATI fut celui de la Gamecube !
#1.7
Ça m'était arrivé une fois, après une mise à jour Windows, de restaurer comme ça des ruches de registres (venant de feu le dossier RegBack), ce qui a fonctionné, puis par essais en machine virtuelle à partir d'une image disque du système défectueux, d'affiner jusqu'à trouver LA clé de registre que la mise à jour avait corrompu (supprimée alors qu'apparemment indispensable pour démarrer).
#2
Perso, j'utilise les outils de virtualisation pour pouvoir faire enfin un truc banal depuis des années sous linux: ajouter une carte réseau sur un VLAN tout en conservant la carte principale pour les paquets sans l'entête 802.1q
C'était une galère sans nom quand seuls deux fabricants de cartes réseaux (intel et realtek), permettaient de le faire via un des pilotes spéciaux et une configuration un peu compliquée.
Pour ceux qui se demande pourquoi faire une telle chose, cela permet de circonscrire le traffic SMB au réseau local Ethernet. Ce qui est dans un VLAN n'est pas routé par les box et n'est pas disponible sur le wifi.
Attention de ne pas utiliser le VLAN 100 cependant avec une freebox car c'est celui utilisé entre le serveur et le lecteur multimédia: un préfixe IPv6 global y est annoncé et il est partagé sur le Wifi et les ports Ethernet.
Historique des modifications :
Posté le 28/06/2024 à 11h34
On peut donc être concernés même si on n'utilise pas directement la virtualisation.
Perso, j'utilise les outils de virtualisation pour pouvoir faire enfin un truc banal depuis des années sous linux: ajouter une carte réseau sur un VLAN tout en conservant la carte principale pour les paquets sans l'entête 802.1q
C'était une galère sans nom quand seuls deux fabricants de cartes réseaux (intel et realtek), permettaient de le faire via un des pilotes spéciaux et une configuration un peu compliquée.
Pour ceux qui se demande pourquoi faire une telle chose, cela permet de circonscrire le traffic SMB au réseau local Ethernet. Ce qui est dans un VLAN n'est pas routé par les box et n'est pas disponible sur le wifi.
Attention de ne pas utiliser le VLAN 100 cependant avec une freebox car c'est celui utilisé entre le serveur et le lecteur multimédia: un préfixe IPv6 global y est annoncé et il est partagé sur le Wifi et les ports Ethernet.
#2.1
Côté Orange, le vlan 835 (reliquat d’une vieille configuration 8/35 de je-ne-sais-quoi) est utilisé pour l’accès à la fibre via l’ONT (mais je crois que c’est uniquement quand on se passe de la Livebox).
Édit : correction du numéro de vlan Orange, merci @renaud07
Historique des modifications :
Posté le 28/06/2024 à 11h48
Ni le vlan 400, d’ailleurs. Je ne sais pas pour quoi il est utilisé exactement mais la Freebox Révolution cherche en permanence une autre machine dessus.
Côté Orange, le vlan 836 (reliquat d’une vieille configuration 8/36 de je-ne-sais-quoi) est utilisé pour l’accès à la fibre via l’ONT (mais je crois que c’est uniquement quand on se passe de la Livebox).
#2.3
#2.2
#2.4
Les plus vieux paranos d'entres-nous (donc moi) utilisent leur propre routeur et font du bridge/double-NAT avec la box. Mais le VLAN est une solution moderne élégante.
#2.5
#2.6
#2.7
640K4 Bytes ought to be enough for anyone."#2.9
le SMB sur IPv6 fonctionne très bien et permet de couper définitivement l’infâme service de nom netbios qui est mécaniquement incompatible IPv6.
Côté serveur, mes machines virtuelles sont quasiment à 100% en IPv6: c'est un mandataire inversé nginx qui reçois les connexions en IPv4 et les retransmet par détection de flux au bon serveur en IPv6 avec le protocole proxy.
Le traffic reste chiffré jusqu'au serveurs finaux car l'aiguillage se fait sur le flux lors de la phase de connexion SSL avec le paquet HELO. Pas besoin de gérer les certificats sur l’hôte.
Il me reste encore une dernière chose à faire pour bouter l'IPv4 de ces machines: mettre en place un NAT64 et un DNS64. Mais tayga est chiant à configurer donc je n'ai pas encore résussi.
#2.10
Et d'être retourné en cours de réseau.
Historique des modifications :
Posté le 29/06/2024 à 10h33
J'ai l'imprimer de lire/entendre un collègue ! 😅
Et aussi d'être retourné en cours de réseau.
#2.11
IPv4, c'est le passé, et il est plus que temps de passer à la suite.
De mon côté, je m'active à lui creuser sa tombe et je fêterai dignement son enterrement.
Historique des modifications :
Posté le 29/06/2024 à 10h55
IPv4, c'est le passé, et il est plus que temps de passer à la suite.
De mon côté, je m'active à lui creuser sa tombe et je fêterai dignement son enterrement.
#2.12
J'imagine que tu parlais de SNI dans le ClientHello de TLS.
#2.13
Globalement, le message que j'essaye de faire passer est pour ceux qui n'ont pas ton degré de compétences. Je reformule donc:
Avec les modules de type flux de nginx, il est possible de router automatiquement les connexions https vers la bonne destination et le protocole proxy sans sacrifier la confidentialité des échanges.
Le mandataire inverse est capable de déterminer cela à partir du tout premier paquet envoyé par le client https car ce paquet est en clair.
Le protocole proxy permet de transmettre au serveur destinataire l'adresse ip du client et d'autres informations.
Du coup, les flux https IPv4 arrivent au mandataire qui les renvoie en IPv6 au serveurs IPv6 only par protocole proxy sur des adresses ULA. Les flux IPv6 arrivent directement aux serveurs.
Bref, il est possible et même très simple d'arrêter de faire du NAT44 comme des idiots pour des serveurs en conteneurs ou en machines virtuelles en migrants sur IPv6
#2.14
Mon degré de compétences comme tu dis s'arrête à TLS; niveau réseau je suis une bille (j'espère que mes profs d'école d'ingé TelCo ne me liront pas ici 😬).
Globalement je fais transporter mes paquets avec IPv6 (VPN, réseau local), mais j'ai encore beaucoup de mal à manier tout ça, parce que je ne trouve pas l'IPv6 super intuitif, les adresses sont terribles à parser pour le grep-with-my-poor-human-eyes…
Il faudrait que j'essaie de jouer avec tout ça et essayer de reproduire ton setup. Ça pourrait être un projet cool.
Sinon, pour ce qui est du routing niveau applicatif, nginx c'est super mais je trouve sa configuration un poil primaire.
J'utilise Envoy personnellement, c'est assez avancé, la configuration s'écrit dans un peu n'importe quoi qui peut se mapper en protobuf.
EDIT: t'as une RFC[1] pour des ClientHello chiffrés en TLS 1.3, c'est cool, et ta confidentialité s'en retrouve encore plus grandie. D'un point de vue on-path attack, il n'y aurait plus que le routing qui pourrait leaker des informations.
Manque plus que OpenSSL le supporte pour l'avoir de-facto dans nginx (BoringSSL le supporte déjà, Envoy utilise BoringSSL).
[1]: https://www.ietf.org/archive/id/draft-ietf-tls-esni-18.txt
Historique des modifications :
Posté le 30/06/2024 à 11h17
Merci pour ces détails! :)
Mon degré de compétences comme tu dis s'arrête à TLS; niveau réseau je suis une bille (j'espère que mes profs d'école d'ingé TelCo ne me liront pas ici 😬).
Globalement je fais transporter mes paquets avec IPv6 (VPN, réseau local), mais j'ai encore beaucoup de mal à manier tout ça, parce que je ne trouve pas l'IPv6 super intuitif, les adresses sont terribles à parser pour le grep-with-my-poor-human-eyes…
Il faudrait que j'essaie de jouer avec tout ça et essayer de reproduire ton setup. Ça pourrait être un projet cool.
Sinon, pour ce qui est du routing niveau applicatif, nginx c'est super mais je trouve sa configuration un poil primaire.
J'utilise Envoy personnellement, c'est assez avancé, la configuration s'écrit dans un peu n'importe quoi qui peut se mapper en protobuf.
#2.8